🎯 By the end of this lecture you will be able to…
- List and explain the essential attributes of a good research problem.
- Apply the FINER and SMART checklists to evaluate a candidate problem.
- Recognise the most common errors students make in problem selection — and avoid them.
- Score and compare two candidate problems objectively.
In Lecture 1 you learned how to find a research problem. But finding one is easy — finding a good one is the skill. A good problem is the difference between research that flows and research that fights you at every step.
1The essential attributes of a good research problem
Across disciplines, strong problems share a recognisable set of characteristics. Learn these seven and you can audit any idea in minutes.
① Clear and unambiguous
If two readers interpret your problem differently, it isn't ready. Every key term must be defined. "Make the app faster" is vague; "reduce median API response time below 200 ms under 1,000 concurrent users" is clear.
② Significant and original
Solving it should add something new — new knowledge, a new method, new evidence. If the answer is already known or trivial, it is engineering homework, not research.
③ Feasible
This is where most student projects die. Feasibility means the problem fits your time, skills, data, compute, and equipment. A brilliant problem you cannot finish is worthless.
④ Specific and well-defined (bounded scope)
A good problem has edges. It says what it covers and what it does not. "Improve cybersecurity" has no edges; "detect SQL-injection in PHP web apps using static analysis" does.
⑤ Measurable / testable
You must be able to gather evidence and know whether you succeeded. If there is no metric, experiment, or proof that could answer it, it isn't researchable.
⑥ Ethical
The investigation must not harm people, violate privacy, or breach consent. Scraping private user data or A/B-testing a change that could hurt users crosses the line. (We return to ethics in Unit III.)
⑦ Interesting & relevant to you
You will live with this problem for months. Genuine curiosity is fuel; boredom is friction. Relevance to your field and career matters too.
2Two checklists you can memorise: FINER & SMART
Attributes are easier to apply when packed into a mnemonic. Two are worth memorising for life.
- F — Feasible: Do you have the time, data, skills, and resources?
- I — Interesting: Does it genuinely engage you (and others)?
- N — Novel: Does it add something new, confirm/refute, or extend prior work?
- E — Ethical: Can it be done without harm and with proper consent?
- R — Relevant: Does it matter to the field, practice, or future research?
Specific · Measurable · Achievable · Relevant · Time-bound. Originally a goal-setting tool, SMART is perfect for pressure-testing whether your problem statement is concrete enough to act on.
Take this statement: "I will use AI to solve traffic." Run it through FINER. How many letters does it fail on? (Hint: at least three.) Rewrite it so it passes.
3Errors in selecting a research problem
Knowing the attributes is only half the battle. The other half is recognising the traps. Here are the errors that sink student projects most often.
"Improve the security of the internet." No individual, in no timeframe, can do this. Broad problems have no measurable endpoint, so you never know when you're done. Fix: apply the funnel from Lecture 1 until one sentence remains.
"Does renaming a variable change my program's output?" Technically researchable, but the answer is known and uninteresting. Fix: ask "so what?" — if there's no meaningful implication, widen it.
"Build a general artificial intelligence for medical diagnosis in one semester." Ambition is good; delusion is costly. Fix: honestly inventory your time, data access, and compute before committing.
"Make the user interface better." Better how? Measured by what? Without a metric there is no research. Fix: attach a variable you can observe (task-completion time, error rate, SUS score).
Spending months on a problem that three papers solved in 2019. This comes from skipping the literature review. Fix: search thoroughly first (Unit III) — novelty is only knowable relative to what exists.
"Analyse WhatsApp's internal moderation logs." You will never get that data. A problem you cannot get evidence for is a dead end. Fix: confirm data and tool access exists before finalising.
If you cannot state your problem in a single, jargon-free sentence that a classmate from another branch understands, it is still too broad or too muddled. Clarity of statement is clarity of thought.
4Putting it together: scoring two candidates
Suppose you're deciding between two ideas. Score each attribute 1–5 and compare — objectivity beats gut feeling.
| Criterion | A: "Detect deepfake videos in real time on a phone" | B: "Compare 3 image-augmentation methods for leaf-disease classification on a public dataset" |
|---|---|---|
| Feasible (semester) | 2 — needs heavy compute, real-time constraint | 5 — public data, modest compute |
| Novel | 4 | 3 |
| Measurable | 4 | 5 — clear accuracy metric |
| Data available | 2 | 5 |
| Scope bounded | 2 | 5 |
| Verdict | Exciting but risky for a short project | Strong student project |
Idea A might be a great PhD problem; Idea B is a great semester problem. "Good" is always relative to your constraints.
✅ Check your understanding
🧠 Key takeaways
- A good problem is clear, significant, feasible, bounded, measurable, ethical, and interesting.
- Use FINER to judge whether a problem is worth doing, and SMART to judge whether it's framed well.
- The six classic errors: too broad, too trivial, infeasible, unmeasurable, already-solved, and no data access.
- Feasibility and data availability kill more student projects than a lack of good ideas.
- "Good" is relative to your constraints — score candidates objectively before committing.
Research Methodology in CS (CSEG3060) · Unit I · Lecture 2 · Dr. Mohsin Furkh Dar · UPES Dehradun